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(57) Abstract 

The invention concerns a 
method for the implementation of 
charging in a telecommunications 
system including customer termi- 
nals used by customers for order- 
ing services and servers for pro- 
viding services to customers. In 
order to implement the charging 
of services easily especially in a 
multimedia environment, at least 
one separate billing server is used 
in the network so that each cus- 
tomer terminal has a dedicated 
billing server. A contract mes- 
sage is sent to the custoi 
minal stating that the c 

lected service, and the ci 
acceptance of the contact is sent 
from the customer terminal to 
the billing server in the network. 
The billing servers of the network 
are used for transferring charg- 
ing records to the billing system 
so that the transfer of the charg- 
ing record(s) concerning the se- 
lected service involves at least 
one billing server. 
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Implementation of charging in a telecommunications system 
Field of the invention 

The invention is related in general to the implementation of 
5 charging in a telecommunications system and in particular to the implemen- 
tation of charging for multimedia services. 



Background of the invention 

Charging for services is implementation of a contract between a 

10 service provider and a customer. In principal, there are two types of charg- 
ing: distributed and centralized. 

In distributed charging the customer pays the vendor each time 
he/she uses the services provided by the vendor. The payment is made 
either in cash or by using some other equivalent method. For example, de- 

15 livery of mail is paid by using stamps. A more recent example of a payment 
method used in distributed charging is electronic cash. Each "coin" of elec- 
tronic cash consists of a encrypted binary sequence, which must be verified 
by the server of a bank. 

In centralized charging, either the vendor or a third party monitors 

20 the usage of services. The customer is charged periodically, for example, 
once a month. The bill is based on data gathered during the previous charg- 
ing period. Three well-known examples of centralized charging are electricity, 
telephone and credit card charges. Centralized charging consists of three 
stages. The first stage is the drawing up of a contract between the user and 

25 the service provider, on the services and the charging for the services. The 
second stage is the monitoring (or metering) and storage of usage data. The 
third stage is the generation and distribution of a bill to the customer. The bill 
is generated in the billing system on the basis of stored information. 

For example, the centralized billing system used in a telephone 

30 network is based on a contract between subscribers and the telephone com- 
pany. The essence of the contract is that the subscriber is given access to 
telephone services, i. e. he/she can make and receive calls. In return he/she 
pays the telephone company on the basis of predefined tariffs. Typically, the 
bills contain charges of two different types: fixed charges and charges for 

35 usage. The fixed charges are charged regardless of whether the services are 
used or not. Charges for usage depend on how many calls a subscriber has 
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made and possibly also on how many calls he/she has received. In order to 
be able to charge for usage telephone company has to monitor the made 
and received calls. The monitoring is connection based; it is done by 
switches in the network. 
5 Figure 1 illustrates a well-known centralized charging method 

used in telephone networks by presenting a part of a public telephone net- 
work. For each call made, the network switch SW (subscriber's local switch) 
creates one or several charging records CDR (Charging Data Record). 
These records are first stored in memory and then sent to a centralized bill- 

10 ing system in which they are stored in a mass memory, for example, in a 
magnetic tape or a hard disk. There may be an additional processing stage 
between the switch and the billing system. In this stage the charging records 
are preprocessed, i.e. prepared, for the billing system. The preprocessing 
may include, for example, a conversion of a tariff class field into another 

15 format. The mass memory of a billing system may contain millions of rec- 
ords. These records form the "raw data", which the billing system processes. 
So the processing of the charging records takes place as a separate batch 
process at a later date than the date of generating the records. It should be 
noted that in practice the charging may be much more complicated than the 

20 example presented here. For example, in a cellular network each participat- 
ing cellular network switch may generate charging records. However, the 
principle of charging is similar to the one presented above. 

From now on, the charging records are referred to as "CDR" and 
the program forming the charging records as the "CDR generator". 

25 The centralized charging of telephone services is based on off- 

line charging and on the fact that in the network there are CDR generators 
that record the setup and release events. However, this kind of charging is 
not technically suitable when multimedia services are offered in the network. 
There are two basic reasons for this. First, most of the current multimedia 

30 services use IP (Internet Protocol), which is used for providing connection- 
less services. Charging based on telephone network connections is not suit- 
able for this kind of system. Second, it is obvious that the charging for multi- 
media services must be based on the content of the transferred information. 
The current telephone network can monitor setup and release events, but it 

35 cannot monitor the content of what is being transferred. When using CDR 
generators, the network operator must choose between two alternatives: 
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either (a) the charging will be based on connections regardless of content or 
(b) in connection with each delivery, information about the content of the 
transferred information is retrieved from the service provider. The first alter- 
native means that the operator cannot offer charging for content; the existing 
5 centralized billing systems of telephone networks cannot be utilized effi- 
ciently. For the customer this means that he/she gets one bill from the op- 
erator and, in addition to that, separate bills from each service provider. The 
second alternative leads to a highly integrated, technically complicated sys- 
tem in which there is much traffic between servers and CDR generators. 

10 One billing system for a telecommunications network is described 

in EP patent application EP-A-0647052. The system has a separate billing 
server which handles the billing for the service providers in the network. In 
the system the customer terminal always reports first to the billing server its 
own identity and the identity of the service desired. The billing server then 

15 determines whether the customer is authorized to receive the service (e.g. 
whether credit needed for the service can be given). If so, the billing server 
sends to the server providing the service and to the customer terminal a 
temporary service key, which allows the customer terminal access to the 
server providing the service. Thereafter the customer terminal sends a con- 

20 nection request message to the server providing the service, whereafter the 
two can negotiate terms of the service before service delivery. When the 
service is delivered, the server providing the service sends a report message 
about the service provided to the billing server, which prepares a bill for the 
customer on the basis of the message. The bill may be sent either by E-mail 

25 or by post, for example. 

The principal drawback to this type of system is that it can not 
benefit from the already existing systems, except for the transmission con- 
nections. For this reason, it is a complicated operation to establish a billing 
service. In addition to this, the information security of the system is not fully 

30 safeguarded, e.g. as far as non-repudiation is concerned. This means that 
the customer must have total trust in the accuracy of the amount of the bill 
generated by the billing terminal. It is also impossible for the customer to 
have any say in the amount of the resulting bill, for example, in cases where 
the quality of the service at the customer terminal is poor, e.g. due to delays 

35 or other imperfections in the network, since the server has delivered the 
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service as agreed. This is of particular significance in continued long-term 
service. 

Summary of the invention 

5 The purpose of the invention is to eliminate the above-mentioned 

disadvantages and create a solution which makes it possible, for example, to 
use centralized charging for billing multimedia services utilizing the existing 
systems as efficiently as possible. 

This goal can be attained by using the solution defined in the in- 

10 dependent patent claims. 

The basic idea of the invention is to use in the system at least 
one separate device (called a "billing server"), which, on the basis of the 
service selected by the customer, negotiates an on-line contract with the 
customer; or which at least can verify that the customer has accepted the 

15 service on defined terms. Billing servers act as points from which the charg- 
ing records are sent to the actual billing system and, additionally, they can 
verify the correctness of the charging records created by the customer termi- 
nal before storing and/or sending them forward to the billing system. So, in 
practice the solution is in great extent based on the existing implementation 

20 in the telephone network, the difference being that instead of the measuring 
of service usage and generating of charging records or messages related to 
them taking place in the network, they take place in the customer's terminal, 
which sends the charging records to a separate billing server. 

A system based on the invention is easy to implement as it util- 

25 izes the existing solutions as much as possible. Additionally, the principles of 
the system are such that it is easy to implement all the factors essential to 
data security: authentication, data integrity, non-repudiation (a party to the 
data transfer cannot deny participation in the transaction) and privacy (an 
eavesdropper cannot interpret any captured data). 

30 The system also makes it easier for new service providers to start 

operation, because there is an existing billing solution (i.e. the billing system 
of the telephone network). They do not need to invest in the implementation 
of charging. 

The customer also has the possibility to have an immediate effect 
35 on the resulting bill, e.g. in cases where the quality of the service received by 
the customer was poor due to delays or other imperfections in the network. 
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The system also allows the usage of parallel methods of pay- 
ment, for example, electronic money can be implemented as an alternative, 
or parallel payment method in a system based on the invention. Additionally, 
the system makes it possible to monitor the service level used by the cus- 
5 tomer. As the monitoring is done in the customer terminal, which also gener- 
ates the charging records, the process of generating the charging records 
can react quickly to the changes in the service level. In addition, the system 
is easily scalable. 

The solution is also suitable for use in a mobile or cellular net- 
1 0 works, so the usage of services is not geographically limited. 

A solution in accordance with the invention can be used in very 
different communications solutions as it is independent of data transfer pro- 
tocols and methods. 



1 5 Brief description of the drawings 

In the following, the invention and its preferred embodiments are 
described in detail referring to the examples 2-10 in the attached figures: 



Figure 1 illustrates a known charging method used in telephone networks, 
20 Figure 2 illustrates the network environment in which the invention is to be 
used, 

Figure 3a illustrates the message transfer between the different compo- 
nents of the system before starting the actual charging, 

Figure 3b illustrates the situation corresponding to Figure 3a when a gate- 
25 way is used in the network between the billing server and servers 

providing the services, 

Figure 4 illustrates the contract window displayed on the customer termi- 
nal, 

Figure 5a illustrates an example of message transfer between customer 
30 terminal and billing server during one charging session, 

Figure 5b illustrates a situation in which the clocks of the billing server and 
the customer terminal are skewed in relation to each other, 

Figure 6 illustrates the content and structure of a charging record, 

Figure 7a illustrates the structure of the customer terminal as a functional 
35 block diagram, 
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Figure 7b illustrates in detail the structure of the CDR generator shown in 
Figure 7a, 

Figure 8 illustrates the structure of the billing server as a functional block 
diagram, 

5 Figure 9a illustrates a case in which the customer uses services from a 
server, which does not belong to the area managed by the cus- 
tomer's own billing server, 
Figure 9b illustrates the message transfer between the billing servers in the 
case presented in Figure 9a, and 
10 Figure 10 illustrates an example of message transfer when the customer 
terminals are located in a cable TV network. 

Detailed description of the invention 

In the following, the invention is described in detail referring to the 

15 example in Figure 2, which illustrates a system based on the invention in a 
typical operating environment. 

The system includes customer terminals (CTs), located at cus- 
tomers' premises. These can be, for example, personal computers, mobile 
stations or separate customer terminals, which are connected to conven- 

20 tional terminal equipment. The terminal equipment may also be integrated, 
for example, into a modem. 

Additionally, the system includes at least one billing server WD, 
which collects and verifies charging records generated by the customer ter- 
minal. The billing server may be located, for example, on the edge of the 

25 Internet, in connection with the servers of an Internet service provider ISP. 
Logically, the location of the billing server has no meaning, but in practice the 
selection of the location is affected, for example, by the following factors. 
First, it is advantageous to place the billing server in connection with or near 
the public telephone network so that it has easy access to the existing billing 

30 system of the telephone network. As regards efficiency, it is essential that 
the connection between the customer terminal and the billing server is as 
fast as possible and the delay is easily controlled (which is not the case at 
present, if the billing server is, for example, deep in the Internet). As the 
purpose of the system is also to provide local service (in a geographically 

35 limited area) so that the customers are billed for the services, for example, 
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once a month, it is not sensible to locate the billing server far from the cus- 
tomers. 

The billing server includes a memory MS, a magnetic tape for ex- 
ample, which is used for storing all of the charging records the billing server 
5 has accepted. The gathered charging records are transferred periodically to 
the billing system BS, which is an existing billing system in the public service 
telephone network PSTN, or, for example, a system similar to the existing 
billing system, but located in a broadband network. Before transfer to the 
billing system, the charging records can be stored temporarily on a mass 

10 memory device MS 1. 

Additionally, the system includes service providers, which offer 
those services for which the customers are charged by using the system in 
accordance with the invention. To simplify Figure 2, only one service provider 
is included (SP1). This service provider may offer, for example, Video-on- 

15 Demand service via the Internet. 

The customer terminal (CT), can be connected to the network in 
different ways as illustrated in Figure 2. For example, ISDN connections are 
a possible option. An ISDN connection can be implemented, for example, via 
a normal router (R) in which case TCP/IP protocol is used over the ISDN 

20 connection, or via an ISDN card and an ISDN basic access (BRI). The cus- 
tomer terminal can also be connected to the network switch via a modem 
and an analog subscriber line. Additionally the current Asymmetrical Digital 
Subscriber Line (ADSL) and High bit rate Digital Subscriber Line (HDSL) 
techniques offer new possibilities for fast transfer of data and video in a tele- 

25 phone network twisted pair line to the subscriber terminals. Later on, the 
system could be used, for example, for ATM connections. The customer 
terminal can also be located, for example, in a local network of a company or 
other organization or it can be a cable TV network terminal. An Internet 
service provider can also connect to the network switch, for example, via 

30 ISDN primary access (PRI). 

The following describes in more detail the operation of the system 
in accordance with the invention. The example assumes that the billing 
service provider is a separate organizational unit, which handles only the 
billing of services via the billing server WD, which it controls. Thus the billing 

35 service provider has its own billing system BS. 
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Initially, the billing service provider makes a long-term contract 
with each service provider. In this contract, the billing service provider agrees 
to monitor the usage of services and to collect the charges for the usage. As 
compensation for this, the billing service provider may get a certain part of 
5 the profit for the services or a fixed fee. As a result of the contract, each 
service provided by the service provider gets a unique identifier, which is the 
same both in the billing server (WD) and in the service provider's server 
(SP1). Additionally, each identifier is given billing parameters, which are used 
by the billing server. So, in the primary embodiment of the invention the 

10 billing server has a database that includes billing parameters for each service 
identifier of each service provider. As will be described later, this method of 
implementation can be changed, for example, in a way that the parameters 
in question are transferred from the server of the service provider to the 
billing server at the beginning of each session. 

15 After this, the billing service provider makes long-term contracts 

with customers (those persons who use the services offered by the service 
providers). Each customer gets a unique customer identifier, which is stored 
in the billing server and possibly also in the server of the service provider. 
Additionally, each customer gets a pair of keys consisting of a public key and 

20 a private key. This pair is used for signing and signature verification of 
charging records. The public key of the customer is stored in the billing 
server and the private key in the terminal equipment. In the primary embodi- 
ment, only the customer knows the private key. It is also possible to define a 
profile for the customer. 

25 The use of service can begin after these long-term contracts are 

established. 

After the customer has selected a service, but before starting the 
charging, a (short-term) on-line contract is made between the customer and 
the system. The contract covers only the service the customer has just se- 
30 lected, for example, viewing one movie, or making one purchase. The fol- 
lowing explanation refers to Figure 3a, which illustrates the forming of an on- 
line contract. In the figure, the databases connected to the billing server are 
service, billing and subscriber databases. 

The customer terminal CT, includes a service browser (which can 
35 be, for example, a Web browser), which the customer uses to find suitable 
services from the Internet. After finding a suitable service, which in this ex- 
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ample is the Video-on-Demand service of service provider SP1, the cus- 
tomer selects the service in question (for example, a movie) by clicking the 
option, for example. The service selection stage is indicated by arrow A. So 
at this point the customer terminal and the server of the service provider 
5 communicate. 

When the customer has made the selection, the server of the 
service provider sends to the billing server WD, (arrow B) the service identi- 
fier "Sid", identifying the movie in question, and the subscriber identifier "Cid" 
of the customer in question. The Cid is obtained, for example, from the cus- 

10 tomer's browser on the basis of the source address of the received mes- 
sages (for example, the socket address of the TCP connection). So the 
browser is always required to provide the customer identity and address, at 
least to the billing service provider, but preferably also to the service pro- 
vider. The subscriber identifier can also be, for example, retrieved from a 

15 database on the basis of a password given by the subscriber. This way sev- 
eral different customers can use the services from the same address. It is 
also possible that there is in the network a separate server, which hides the 
customer's identity from the service provider, but gives the information to the 
billing service provider. However, this kind of arrangement is more compli- 

20 cated. 

After this, the billing server WD starts a process, which handles 
the usage of the service in question. First the billing server retrieves from the 
service database the parameters corresponding to the service in question 
and sends (arrow C) a certain type of charging record (CDR) to the customer 

25 terminal. The charging record contains the billing parameters to be used 
during the session in question and the contract number. After receiving this 
initial charging record, the customer terminal program opens a window on 
the customer terminal, which is from now on referred to as a contract win- 
dow. Figure 4 illustrates an example of a contract window using fictional 

30 server names. The window displays, on the basis of the information received 
from the billing service, the basic data about the different parties and the 
service in question. Additionally, the window displays the contract number, 
which identifies this particular service session. The difference between this 
contract and the above-mentioned long-term ones is that this contract is 

35 short-term; it concerns only the current service session. So this contract 
covers only, for example, the viewing of the selected movie. By clicking the 
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Accept button, the customer accepts the service and the basis for the 
charging of the service. The customer can call off the service by clicking the 
Cancel button. The customer can also program the terminal to automatically 
accept the service, for example, in cases where the total price or the price 
5 per time unit is less than a predefined value. 

As a result of customer acceptance, the customer terminal returns 
to the billing server the charging record it received from there. However, the 
charging record to be returned includes a digital signature (Figure 3a, arrow 
D). A digital signature refers to a known encryption algorithm based on a pair 

10 of keys. The encryption is done using a private key while anybody can de- 
crypt the message using a public key. The confidentiality of the message is 
lost in this way, but it makes it sure that the message has come from the 
correct source. So the sender cannot later deny the fact that he/she has sent 
the message. When using a digital signature, the entire message is normally 

15 not encrypted, only the digest formed from the message. The digest is a sort 
of check sum. From the encryption point of view, this digest is very strong 
and an outsider cannot create a message, which would have an identical 
digest. The digest and the time stamp are encrypted by using the sender's 
private key and these form the digital signature. There are several different 

20 known options for implementing the signature, but as the invention is not 
related to the signing of messages, the implementation of signatures is not 
described in more detail here. Anyone interested in the matter can find more 
detailed information from several books describing the field. (For example, 
see Schneier, Applied Cryptography, ISBN 0-471-11709-9, Wiley & Sons, 

25 1996.) 

After this the billing server WD verifies the signature by using a 
known method in order to authenticate the CDR. For this purpose the billing 
server retrieves from its subscriber database the public key for the customer 
in question (arrow E). The billing server stores the accepted charging record 
30 into its billing database (arrow F) for some time in case the customer makes 
a reclamation on the service at a later date. After this the billing server asks 
the service provider to start sending the information to the customer (arrow 
G). 

The procedure described above can be varied, for example, so 
35 that server SP1 sends, after the customer has selected the service, the 
service identifier and other possibly required information directly to the cus- 
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tomer terminal, which sends the service identifier again to the billing server. 
To prevent the customer from changing the service identifier, the server must 
add to the message a digital signature, which the billing server recognizes, 
or the billing server must verify the service identifier separately from the 
5 server SP1 after it has received the identifier from the customer terminal. 
Another variation is to let the server SP1 form the initial charging record, 
which contains the billing parameters to be used during the service session 
in question. In this case the billing server only verifies the message and 
sends it to the customer terminal, or the billing server can add the contract 

1 0 number to the message. 

It is also possible to use a separate gateway computer in the 
network between the billing server and the servers of the service provider. In 
this case the gateway computer has a list of available services and server 
SP only contains the actual service information (for example, the video data). 

15 Figure 3b illustrates the formation of the on-line contract when using this 
option. So in this case the gateway computer GW handles the same opera- 
tions as the server in the option presented in Figure 3a. When the gateway 
computer has received from the billing server a request for sending informa- 
tion (arrow G), it sends the server a starting request (arrow H), which con- 

20 tains the customer terminal address and the service identifier. In this em- 
bodiment, an additional checking can be used so that the gateway computer 
checks separately from the server whether the required service can be deliv- 
ered to the customer. There may be several reasons for this additional 
checking, which is marked with a dotted line in Figure 3b, for example, 

25 checking the server load. The billing server and the gateway computer need 
not be physically separate; they can be integrated into one computer. 

The following describes the operation of the method after the on- 
line contract has been made by using one of the implementation methods 
described above. 

30 After the service has begun (for example, the movie has started), 

the customer terminal sends, for example, periodically, charging records 
which have digital signatures and which contain information about the 
amount to be charged. So each CDR to be sent represents charging of a 
certain time period and the total charge is obtained by summing the charged 

35 amounts in all of the charging records that have the same contract number. 
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The time between two consecutive CDRs (and thus the charge for one CDR) 
may depend on the service provider. 

The billing server verifies the origin of each charging record by 
using the public key of the customer, and stores the accepted charging rec- 
5 ords to the billing database. 

From the billing database the charging records are periodically 
transferred to the billing system BS (Figure 2) where they are used to form 
bills by using a known method. The bills are to be sent to the customers. 
One bill contains a list and charges for all of the services that the customer 
10 has used during the charging period (for example, one month). The bill can 
be delivered as a printed copy via mail, or in electronic form to the customer 
terminal. Since the operation of the billing system is known, it is not de- 
scribed in more detail here. 

There can be, for example, nine different types (0-8) of charging 
1 5 records (charging messages) in the system as follows: 

0. Contract: This is the initial charging record (arrow C, Figure 3) 
that the billing server sends (unsigned) to the customer and that the cus- 
tomer terminal returns to the billing server signed, if the customer accepts 
the contract, 

20 1. Payment: This type of charging records are sent with a signa- 

ture during a service session from the customer terminal to the billing server, 
which verifies them. 

2. Final: This type of CDR corresponds to type 1 in other re- 
spects, but it includes as additional information a statement that it is the last 

25 CDR the customer terminal is going to send during the current service ses- 
sion. This type of record is sent, for example, when the customer interrupts 
the service. It can also be used for one-time charges. 

3. Pulse: This type of CDR is sent from the billing server to the 
customer terminal. The purpose is to tell the customer terminal that it should 

30 send a new CDR, if the service is to be continued. If the customer terminal 
does not send a valid CDR during a specified period, the billing server sends 
an interruption message to the server of the service provider. 

4. Missing sequence number: This is sent from the billing server 
to the customer terminal (during a continuous billing contract) to notify that a 

35 CDR having a certain sequence number has not arrived to the billing server 
or that the CDR was not valid. In this case the customer terminal can send 
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the CDR again to correct the situation. However, this kind of functionality is 
not necessary for either party. If the customer terminal does not answer this 
type of CDR, the best option is that the billing system has no right to charge 
for the portion of the missing CDR. 
5 5. Modified contract: This type of CDR is sent from the billing 

server to the customer and it corresponds to type 0 charging records in other 
respects, but it does not have a new contract number. The contract number 
is the same as the number of the short-term contract in use at that moment. 
This charging record is sent during a service session to notify that the billing 

10 parameters have changed. The customer terminal can, for example, accept 
the new contract automatically, if the price has been decreased; in other 
cases the customer's acceptance may be required. 

6. Abort: This type of CDR can be sent in either direction to indi- 
cate that the contract is to be terminated. The sender signs the CDR. 

15 7. Digital cash: It is also possible to utilize the billing system in a 

way that a CDR (type 1 or 2) connected to certain payment includes the 
payment in digital cash. However, the billing server does not transfer the 
digital cash into the billing system. The billing server transfers it directly, for 
example, to the server of the bank (always when it has collected a certain, 

20 relatively small, amount of digital cash) or to a network server maintained by 
some other organization (server BS' in Figure 2), which charges the cus- 
tomer's account directly. In addition to the centralized billing system BS, 
digital cash can be used for normal electronic trade or as an alternative im- 
plementation instead of a centralized billing system. 

25 8. Synchronization of charging: This is sent from the billing server 

to the customer terminal (during a continuous billing contract) to inform that 
the payment CDRs are sent too frequently. In this case the customer termi- 
nal can skip one sending of a payment CDR. 

Figure 5a illustrates an example of message transfer between 

30 customer terminal and billing server. The type of each message is stated 
above the arrow representing the message. Messages with digital signatures 
are shown as continuous lines and messages without digital signatures (only 
one such message exists and it can also be signed) are shown as dotted 
lines. The figure illustrates a case in which the billing server notices once 

35 during the service that a certain charging record is missing. 
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Depending on the number of processes executed simultaneously 
on the customer terminal, the time (T) between two consecutive type 1 CDRs 
can vary. If the load of customer terminal increases very much and the CDR 
generation is delayed from the nominal value, the charge included in the 
5 CDR is correspondingly greater. 

In practice, continuous charging contains a synchronization 
problem caused by wandering of the customer terminal clocks. As a result it 
may happen that the customer terminal does not send information at the 
right rate. This problem can be solved, for example, by letting the billing 

10 server accept an "error" of a certain size in the total amount of collected 
charges (for example, 3 per cent). This "error" may be increased by less 
accurate calculation/rounding off in the customer terminal. If the "error" is 
increased during a charging session so that it becomes greater than what 
the billing server can accept, the billing server sends a type 4 charging rec- 

15 ord having a sequence number, which is the sequence number of the most 
recent charging record plus one. After this, there are several alternatives for 
the customer terminal to return the charging record in question. The cus- 
tomer terminal can, for example, be programmed to accept automatically all 
charging records of this type, which have an amount that is smaller than a 

20 certain predefined limit. 

Figure 5b illustrates the situation defined above by presenting 
consecutive time frames of the billing server with reference mark WDTF and 
the customer terminal time frames under them with reference mark CTTF. 
The customer terminal sends at the beginning of each time frame a payment 

25 CDR (type 1 ). When there is a time frame in the billing server for which there 
is no payment, the server sends a type 4 CDR. In this case, the customer 
terminal answers automatically by sending a payment CDR and right after 
that the following payment CDR when the next customer terminal time frame 
begins. 

30 If the customer terminal clock is too fast, the customer terminal 

sends at some point two payment CDRs during one billing server time frame. 
This kind of situation can be corrected, for example, in a way that the billing 
server sends an extra message to the customer terminal. This extra mes- 
sage is the logical opposite of the type 4 CDR. After receiving the extra CDR, 

35 the customer terminal skips one payment CDR. For this purpose, a separate 
CDR type is required (type 8). 
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All charging information required in the system is transferred in 
the consecutive fields of protocol messages (charging records). Figure 6 
illustrates the fields used in the charging records: 

TYPE: States the type of the CDR, that is, which one of the eight 
5 above-mentioned charging records is in question. 

LENGTH: This field states the total length of the CDR in bytes, in- 
cluding type and length fields. 

CONTRACT NUMBER: This field includes an integer number 
given by the billing server. The number is the same for all CDRs, which be- 
10 long to the same charging session. 

SEQUENCE NUMBER: An integer number, which states the 
generating order of the CDRs during the same charging session. The cus- 
tomer terminal gives number 0 to the contract CDR (type 0) it returns. After 
this it increases the number by one for each CDR. This field is not defined in 
15 CDR types 3, 5, 6 and 7, and in type 4 it indicates the sequence number of a 
missing CDR. 

SERVICE IDENTIFIER: The contents of this field state the service 
for which the customer is charged. The parameter in this field obtains its 
value as a result of a contract between the billing service provider and the 
20 (multimedia) service provider. 

SERVICE TYPE: The parameter in this field categorizes the 
services in different classes for statistical purposes. For example: Web 
pages, Video-on-Demand, file transfer, etc. 

STARTING TIME: The parameter in this field shows the current 
25 time for CDR types 0 and 5 and also 3, 4 and 6, and the starting time of the 
charging period for types 1 and 2. 

ENDING TIME: The parameter in this field defines the ending of 
the charging session for CDRs of type 1 and 2. For CDRs of type 0 and 5, 
the difference between the starting and ending times is the maximum charg- 
30 ing period acceptable. In CDRs of other types this parameter is not defined. 

IDENTIFIERS: The parameter in this field states the customer, 
billing server and server identifiers. The identifiers can be integer numbers or 
network addresses, but they must be unique within the billing system. 

METHOD OF PAYMENT: The parameter in this field is defined 
35 for CDRs of type 0, 5, 1 and 2. The methods of payment may be catego- 
rized, for example, as follows: free, one-time charge (one CDR), periodical or 
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externally triggered, that is, another process in the customer terminal may 
trigger it. For example, the customer terminal video player can trigger the 
CDR generation once a minute, if acceptable video signal has been received 
during the most recent minute. 
5 AMOUNT OF MONEY: This field states the customer's debt 

(either for the entire session or for a time period between two CDRs). 

TRAFFIC DATA: This field contains information sent from the 
customer terminal's external application to the customer terminal and further 
to the network. 

SIGNATURE: This field contains the customer's digital signature, 
which is used for the authentication of the CDR. 

In the Appendix 1, enclosed in this application, the CDR structure 
is described in more detail by using the Abstract Syntax Notation 1 (ASN.1), 
which is a common description language used in telecommunications for 
describing data structures. Abstract syntax description language and the 
corresponding transfer syntax, which is a set of instructions for presenting as 
a bit stream the data structures described by using a description language, 
are defined in the ISO 8824 standard. 

Charging records can be sent, for example, in the data field of IP 
packages, which may contain one or several charging records. 

Figure 7a illustrates the operation of the customer terminal (CT) 
as a functional block diagram. As regards the invention, the core of the 
equipment is the CDR generator (CG), which generates charging records. 
Connected to the CDR generator is the security library (SL). Its memory 
contains the customer's private encryption key and it handles the signing of 
the charging records. The CDR generator creates the CDRs and sends them 
to the security library where they are signed by using the customer's private 
encryption key. The security library returns the signed CDRs to the CDR 
generator, which sends them to the billing server (WD). 

If the application or the environment is such that encrypted mes- 
sages must be transferred between the customer terminal and the billing 
server, the security library handles the encryption, signing and signature 
verification. 

The security library can be implemented as a hardware based, or 
a software based solution. However, the hardware based solution is faster. 
The security library, or part of it, can be implemented, for example, by using 



WO 98/21676 



17 



PCT/FI97/00685 



a smart card, which contains, for example, the private encryption key of the 
customer. 

Additionally, the customer terminal contains elements for receiv- 
ing the service. These can include, for example, a service player VP, which 
5 can be a video player, which shows the video signal received from the net- 
work and which can also give the CDR generator commands for generating 
the charging records. The service browser SB, the service player VP and the 
CDR generator are connected to the network via the communications library 
CL of the terminal. The CL forms the protocol stack according to which the 

10 customer terminal operates. This protocol stack can be, for example, a 
TCP/IP stack, for example, Microsoft Winsock. 

The customer terminal can also contain a billing counter BC, 
which the customer can use to check the accuracy of the bill sent by the 
service provider. Additionally, the customer terminal can have different com- 

15 ponents for monitoring the quality of service (QoS) of the received informa- 
tion. For example, a video player can order the source to stop transferring 
information when the quality of service falls below a certain level. 

Figure 7b illustrates in more detail the functional block diagram of 
the CDR generator. The contract logic unit CLU1 handles the generation of 

20 charging records on the basis of information stored in the configuration data- 
base CDB. It contains the logic, which transfers the received contract infor- 
mation to the graphical user interface GUI and generates the kind of charg- 
ing records defined above. This logic includes timing components, which 
define the time between two consecutive CDRs. The contract logic unit CLU1 

25 is connected to the communications library and the network via an external 
control interface ECI and to the service player via an internal control inter- 
face ICI. The external control interface makes the conversion between the 
internal and external CDR format. The internal control interface handles 
message transfer between the service player and the contract logic unit and 

30 makes the necessary conversions between the message format used by the 
service player and the internal message format of the equipment. The con- 
nection between the internal control interface and the service player 
(interface A3) can be implemented, for example, by using a communications 
library (TCP socket). The configuration database CDB is used for storing the 

35 settings the user has made (user preferences) and it can be used for storing 
information about different services (for example, movies), which are pre- 
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sented to the customer on the basis of the received service identification. 
This database can be implemented, for example, by using Microsoft Access 
or Borland Paradox. The configuration database is controlled using the man- 
agement unit MM. The management unit, the configuration database and the 
5 contract logic unit are all connected to the graphical user interface (GUI) of 
the device. The GUI can be implemented by using, for example, Java ap- 
plets or Microsoft Visual Basic programming tools. (Java applets are small 
program packages, which are transferred to the user's computer when the 
user opens a Web page containing applets.) Note that part of the configura- 

1 0 tion database can be located in the network. 

If the service player is designed, for example, for Video-on- 
Demand, it can be implemented, by using a personal computer and a pro- 
gram designed for Video-on-Demand services. One such program is 
Streamworks, which is produced by Xing Technology Inc., USA. 

1 5 The management unit and the contract logic unit are connected to 

the security library via the A1 interface. The security library and the A1 inter- 
face can be implemented, for example, by using the SETCOS 3.1 smart card 
produced by Setec Oy or by using some equivalent product, which is based 
on international standards on smart cards. 

20 The data transfer methods used in the implementation of the 

method vary according to the type of network and the method used for con- 
necting the customer terminal to the network. If the customer terminal is 
connected to the network, for example, via a router (IP channel), the charg- 
ing records can be sent in TCP frames. If the customer has, for example, an 

25 ISDN connection (2B+D), the CDRs can be sent in the ISDN signalling pack- 
ets (User-to-User messages) on the D channel or, for example, a TCP con- 
nection can be implemented on one of the B channels. The charging records 
can also be sent, for example, in the TCAP messages of an SS7 network. 
The essential part as regards to the data transfer is only that between the 

30 customer terminal, the billing server and the server there is the required 
connectivity, which makes it possible to transfer the messages defined 
above. 

The method of transferring information from the service provider 
to the customer is not described above as it is not directly related to the 
35 invention. The information can be transferred in packets (as is done in the 
Internet at the present) or dedicated connections (either fixed or virtual) can 
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be used for the transfer. Some service - Video-on-Demand, for example - 
may require a dedicated connection between the customer and the server. 
The network operator may charge these connections separately, but if a 
certain charge for the usage of these connections is to be included in the bill 
5 in the system in accordance with the invention, the CDRs generated by the 
network switches must be collected. In this case it would to advantage if 
these CDRs contained the contract number, because then the price of con- 
nections could be related to the service which caused the forming of the 
connection. So it is beneficial that the calling party sends the contract num- 
10 ber to the switch. This can be done, for example, by using the control mes- 
sages related to the forming and disconnecting of the connection (connection 
through which the service is implemented). The connections and use of 
service can also be connected to each other by using time stamps in the 
CDRs. 

15 Figure 8 illustrates the structure of the billing server WD as a 

general level block diagram. The core of the equipment is the contract logic 
unit CLU2, which has access to the service database SED, the subscriber 
database SUD and the billing database BD. The service database contains 
information about the services of different service providers and the pa- 

20 rameters for charging for the use of the services. The billing server can also 
change the charging parameters independently, for example, on the basis of 
the time of the day. The subscriber database contains the customer data for 
the operator managing the billing server (including the public key of each 
customer). The charging records received from the customer terminal are 

25 stored in the billing database. An encryption block (CM) is associated with 
the contract logic unit. The CM handles the verification of the charging record 
signatures. This block corresponds to the SL block of the customer terminal. 
The contract logic unit receives from the customer terminals charging rec- 
ords signed by the customer terminals and sends them to the encryption 

30 block to be verified. The contract logic unit stores the accepted charging 
records to the billing database. The contract logic unit is connected to the 
network through the communications library (CU), which forms the protocol 
stack defining the connection to be made. 

In practice, the contract logic units described above can be im- 

35 plemented, for example, by using tools based on the international System 
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Description Language (SDL) standard, for example, the SDT tool of Telelogic 
AB. 

The databases of the billing server can be in the memory MS de- 
scribed above (Figure 2) and located in connection with the billing server. In 
5 addition, the charging records can be stored in a separate mass memory 
MS1 (Figure 2), which is between the billing server and the billing system in 
the network and which is organized in such a manner that the billing system 
can easily handle the information stored in it. By using this kind of separate 
database it is possible to let the service providers use the database for dif- 

10 ferent kinds of queries in order to improve their services. The service pro- 
vider, or a customer can, for example, ask about the charging of a certain 
service during a charging period (for example, by using e-mail). 

The subscriber and service databases can be both in the billing 
server and in the service provider's server (the latter can use them, for ex- 

15 ample, for data authentication). These databases can be maintained by 
different organizations and they do not need to be identical. For example, 
free services do not need to be stored in the billing server database. Also, 
the subscriber and service records in the databases need not be identical. 
Only those subscriber and service identifiers that the server providing the 

20 service sends to the billing server must be identical. 

The billing server can consist of several parallel server units and 
known load distribution principles can be used in connection with them, for 
example, by equipping them with a common load sharing unit, which distrib- 
utes the service requests between the parallel units in a certain way. 

25 A service provided by utilizing the invention is meant to be local in 

the respect that one billing server handles a certain group of customers, 
which are located in a geographically limited area. Figure 9a illustrates areas 
SA and SA' managed by two different billing servers, WD1 and WD2. Natu- 
rally, it is possible for a customer of a certain billing server to use services 

30 from a server, which is located in the area managed by a different billing 
service provider (and thus, a different billing server), for example, in another 
city or country. Figure 9a illustrates this kind of situation, in which customer 
C1, located in the area managed by billing server WD1, contacts server S3, 
which has an agreement with the billing service provider managing the billing 

35 server WD2. Figure 9b illustrates the transfer of messages. 
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When the billing server WD2 receives the customer identifier 
(Cid), (or the address) and the service identifier Sid from the server S3, it 
notices that the customer in question is not one of its own. In this case, the 
billing service providers must make a mutual contract so that the billing 
5 server WD2 can send, after receiving the customer and service identifiers 
from the server S3, the initial CDR (contract CDR) to the billing server WD1. 
The latter (i.e. WD1) converts the billing server specific information (billing 
server identifier and contract number) to correspond with its own information 
and, after this, sends the initial CDR to the customer in question. The con- 

10 tract CDR received from the billing server WD2 is linked to the contract CDR 
sent to the customer by storing in the billing server WD1 an "empty" CDR, 
which is otherwise the same as the signed contract CDR received from the 
billing server WD2, but the service identifier has been replaced by the con- 
tract number, which the billing server WD1 uses for identifying the service in 

15 question. This way the billing server WD1 knows that the service originates 
from a service provider, which has a contract with another billing service 
provider. 

After this, the billing server WD1 can collect the CDRs resulting 
from the use of the service. So the situation is similar to what happens when 

20 the customer places an international call. 

Locally collected CDRs can either be processed in the local billing 
system or they can be sent to the billing service provider, who owns the 
billing server WD2. In the telephone network the CDRs are processed and 
the billing is usually handled in the local system. The portion of the billing 

25 belonging to the other operator is returned to them later. 

The example above shows that the method in accordance with 
the invention can be extended worldwide by delegating the making of an on- 
line contract to the local billing server and by using the same management 
methods as in public telephone network. 

30 By adding to the system home and visitor registers similar to 

those in the mobile communications networks, it is possible to implement the 
same roaming properties as in mobile communications networks. In this case 
it is essential that the customer's public key can be safely transferred to the 
billing server near the subscriber so that the billing server in question is able 

35 to verify the charging records. (If the transfer cannot be done safely, it is 
possible that a third party may change the key during the transfer and in this 
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way cause expenses to the original subscriber.) The subscriber's public key 
can be transferred, for example, into a database (VLR, Visitor Location Reg- 
ister) near the billing server into which the billing server has access. The 
billing server nearest to the roaming subscriber can handle the billing by 
5 using the identifier of the subscriber's own billing server. The collected CDRs 
are sent to the subscriber's own billing server after the service session has 
ended. 

A customer terminal can be, for example, a normal mobile station 
into which the properties required by the invention have been added, and the 
10 invention can be used in a mobile phone network or mobile communications 
network. 

If the customer terminals are in a cable TV network, the service, 
for example, playing a video, can be implemented as described below. Be- 
cause a cable TV network is a broadcast network, in which all customers 

15 receive the same signal, the server encrypts the video signal it sends by 
using a key, which it changes frequently, for example, every 5-10 minutes. 
Every time the server changes the key, it informs the billing server of the key 
and the billing server gives the new key to the customer terminal after re- 
ceiving a corresponding payment from the customer terminal. 

20 Figure 10 illustrates the payment of a charge in the case that the 

customer terminals are cable TV network terminals. As a result of making a 
contract, the billing server gives the customer terminal the first key, which it 
has received from the server providing the service. The billing server sends 
periodically a type 3 charging record (pulse) to the customer terminals; in this 

25 way it asks for a new payment. As a response to the payment the billing 
server sends a new key, which is has received from the server providing the 
service. The key can be sent, for example, in a CDR of separately defined 
type (type 9), in which it can be placed, encrypted by using the user's public 
key, to the signature field. The encryption can be implemented when there is 

30 a risk that an outsider could copy the key. The key is sent only to those cus- 
tomer terminals from which a payment CDR has been received. The service 
provider does not need to send one key at a time to the billing server; all 
keys can be sent together. Also, there is no need to make a separate con- 
tract with the customer by using CDRs of type 0. Instead, the sending of the 

35 first key can act as a proposal for an on-line contract from the side of the 
system and the first payment CDR can act as an acceptance of that contract 
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from the side of the customer. After this, the service session is given a con- 
tract number. 

The cable TV application can also be implemented without 
charging records of type 3. In this case the key is sent to each customer 
5 terminal as a response to the payment CDR sent by the terminal. 

Although the invention has been described here in connection 
with the examples shown in the attached figures, it is clear that the invention 
is not limited to these examples as it can be varied in several ways within the 
limits set by the included patent claims. The following describes briefly some 
10 possible variations. 

For example, it is possible that the customer terminal does not 
send actual charging records to the billing server, but it sends some other 
messages, which the billing server can use as a basis of generating the 
charging records. For example, the customer terminal can send so called 
15 keep-alive messages as long as the service lasts, after which the billing 
server generates a charging record in which the duration of the service is the 
time between the last keep-alive message and the time of accepting the 
contract. Charging record(s) can also be generated in the billing server after 
the customer terminal has notified of the acceptance of the selected service 
20 on defined terms. 

In the system described above, the service produced by the 
service provider consists of sending information. In principle, nothing pre- 
vents the service from consisting of a delivery of physical goods (for exam- 
ple, via postal services) to the customer. In this case the charging record(s) 
25 could be generated in the billing server (as the customer terminal cannot 
meter the quality of the service). 

If the connection between the customer and the billing server is 
secure enough, it could be unnecessary to include a digital signature in the 
charging records. Also, sending a separate acceptance message for the on- 
30 line service to the billing server is not necessary as the first payment CDR 
can act as an acceptance of the on-line service from the part of the cus- 
tomer. So, the only essential factor is that some message notifies the billing 
server that the customer has accepted the contract. 

It also possible that the on-line contract is first made between the 
35 billing server and the customer and only after that the server of the service 
provider is contacted. 
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The service can also be implemented as a service session into 
which more than one server participate in addition to the customer terminal. 
One server can send to the customer terminal, for example, a video signal 
while another server sends simultaneously additional information related to 
5 the video signal, such as text or charts. 

If the servers mentioned above have different owners, the pay- 
ment can be divided between them in several ways. For example, the billing 
system can calculate the shares of the service providers when it forms the 
monthly bills. Another solution is that the billing server distributes the pay- 

10 ments right away as follows: for each payment CDR received from the cus- 
tomer terminal, the billing server creates, for example, two new CDRs, which 
it signs and stores into the mass memory. One of these charging records 
contains the payment for the video service and the other for the data service. 
The sum of these payments is the amount of money in the charging record, 

15 which was received from the customer terminal. The method of dividing this 
amount between the service providers is one of the parameters for the com- 
bined service which are stored in the service database. If several servers 
participate in the same service session, the billing server can correspond- 
ingly divide the amount of money received from the customer into several 

20 charging records. In addition to being able to divide the payments between 
the service providers by generating new CDRs, the billing server can also 
take its share right away. So, if there are N number of simultaneous service 
providers, the billing server can divide each received payment CDR into N+1 
portions for the new charging records in a way that each service provider 

25 and the billing service provider get their share. 
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Claims 

1. A method for implementing charging in a telecommunications 
network which includes customer terminals (CT), used by customers for 
ordering services, and servers (SP1; S3) for offering services to the custom- 
5 ers, in accordance with which method 

- a service is selected by means of the customer terminal (CT), 

- a negotiation concerning the terms of the service is carried out 
with the customer terminal, 

- a delivery in accordance with the selected service is made to the 

10 customer, 

- at least one charging record (CDR) is generated to the tele- 
communications network and forwarded to the billing means (BS, BS') for 
charging the customer for the selected service, and 

- at least one separate billing server (WD) is used for charging the 
15 provided services, in such a way that each customer terminal has a dedi- 
cated billing server, 

characterized in that 

- said at least one charging record is generated in the customer 
terminal when the customer accepts the terms of the service, 

20 - the charging records generated by a customer terminal are sent 

to the dedicated billing server of that customer terminal, and 

- the billing servers of the network are used to transfer the charg- 
ing records to the billing means in such a way that at least one billing server 
participates in transferring the charging record(s) of the selected service. 

25 2. A method according to claim ^characterized in that in 

said negotiation a contract message is sent to the customer terminal for 
notifying the customer to make a contract concerning the selected service, 
and that the customer's acceptance of the contract is sent from the customer 
terminal to the billing server. 

30 3. A method according to claim 2, characterized in that an 

identifier for identifying the accepted contract is introduced into said at least 
one charging record. 

4. A method according to claim ^characterized in that 
the charging records are transferred from the billing server to a separate 

35 billing system for forming customer-specific bills. 
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5. A method according to claim 1, characterized in that, in 
response to selection of the service, information identifying at least the cus- 
tomer who made the selection and the selected service is sent from the 
server providing the service to a predefined billing server of the network. 
5 6. A method according to claim 1, characterized in that 

the contract message includes information about charging parameters for the 
selected service, whereby the customer terminal generates charging records 
in accordance with the received charging parameters. 

7. A method according to claim ^characterized in that 
10 the charging records generated are provided with digital signatures, which 

are verified by the billing server (WD). 

8. A method according to claim 5, characterized in that , 
in response to selection of the service, information identifying at least the 
customer who made the selection and the selected service is sent from the 

15 server providing the service via the customer terminal to the billing server 
dedicated to the customer terminal. 

9. A method according to claim 5, characterized in that, in 
response to the selection of a service, information identifying at least the 
customer who made the selection and the selected service is sent from the 

20 server providing the service via the network directly to the billing server dedi- 
cated to the customer terminal. 

10. A method according to claim 8, characterized in that 
the server provides the information it transfers with a digital signature, which 
the billing server identifies when it has been received from the customer 

25 terminal. 

1 1 . A method according to claim 6, characterized in that 
the charging parameters of the service are sent to the customer terminal as 
an unsigned charging record message (CDR) containing the charging pa- 
rameters to be used. 

30 1 2. A method according to claim 11, characterized in that, 

in response to the customer's acceptance of the contract, the charging rec- 
ord received is returned from the customer terminal to the billing server of the 
network as a digitally signed message. 

13. A method according to claim 12, characterized in that 

35 the billing server gives to a server in the network, in response to having re- 
ceived said charging record, a command to start service delivery. 
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14. A method according to claim 13, characterized in that 
the command to start the service delivery is given to a server other than the 
server used for service selection. 

1 5. A method according to claim 1, characterized in that 
5 the charging records are stored both in a memory associated with the billing 

server and in a network mass memory (MS1) providing temporary storage for 
the charging records before they are transferred to the billing means (BS). 

16. A method according to claim 5, characterized in that 
the information identifying the customer who made the selection and the 

10 selected service is sent from the server to a predefined first billing server 
which then forwards it to the customer's dedicated billing server. 

17. A method according to claim 1, characterized in that 
the charging records generated are sent from the customer terminal to the 
nearest billing server, which stores them and then sends the stored charging 

15 records to the customer's dedicated billing server. 

18. A method according to claim 1, characterized in that 
within the framework of a single contract the charging records generated by 
both the customer terminal and the telecommunications network switches 
are collected. 

20 19. A method according to claim ^characterized in that 

the delivery in accordance with the service is carried out by sending informa- 
tion to the customer terminal simultaneously from several network servers. 

20. A method according to claim 1 or 19, characterized in 
that new charging records are generated from the charging records received 

25 by the billing server in order to send them to the billing means. 

21. A system for implementing charging in a telecommunications 
network including servers (SP1; S3) for offering services to customers, the 
system comprising: 

- customer terminals (CT) connected to the network and used for 
30 selecting the services from the servers, 

- charging record generating means (CG) for generating charging 
records as a response to the service provided to the customer, 

- billing means (BS) for receiving the charging records; 

- at least one separate billing server (WD; WD1, WD2) in the net- 
35 work, each customer terminal having a dedicated billing server, 

characterized in that 
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- the charging record generating means are adapted to the cus- 
tomer terminals (CT), 

- the charging record generating means of an individual customer 
terminal are adapted to send the generated charging records to a predefined 

5 billing server of the network, and 

- the billing servers of the network handle the transmission of 
charging records to the billing means (BS). 

22. A system according to claim 21, characterized in that 
the billing means form customer-specific bills, which are sent to the custom- 

10 ers. 

23. A system according to claim 21, characterized in that 
the billing means charge the customers' accounts directly. 

24. A system according to claim 21, characterized in that 
the customer terminal (CT) includes means (SL) for adding a digital signature 

15 to the generated charging record, and the billing server (WD) includes means 
(CM, SUD) for verifying the digital signature. 

25. A system according to claim 21, characterized in that 
the customer terminal (CT) and its dedicated billing server (WD) include 
interactive elements, by the use of which 

20 - the billing server can command the customer terminal to open a 

contract window which presents information about a service and an accep- 
tance button for accepting a contract for the service, and 

- the customer terminal sends, in response to the pressing of the 
acceptance button, contract information and a signature to the billing server. 

25 26. A system according to claim 21, characterized in that 

the customer terminal includes a service player, which is connected to the 
means for generating the charging records, for stopping the generation of 
charging records when the quality of the signal received by the service 
player decreases. 
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- The CDR structure 



5 - In the initial version the encoding is byte-oriented 

- without tag and length fields. ENUMERATED is encoded 
~ as one octet if nothing else is specified, INTEGER 

~ is encoded as an octet string (length 2, 4 or 8 depending 

- on the maximum size) in MSB first format. 

10 

CDR_cdrType ::= ENUMERATED { 

contract (0), - initial CDR, WD -> Client 
payment (1), - normal payment CDR 
final (2), - as above, client stops 
1 5 pulse (3), - indication of new payment 

missing_seq (4), - CDR with seq.num. lost 
mod_contract (5), - contr. renegotiation 
abort (6), - end connection, no money inc. 
E_cash (7) -- e_cash carrier CDR, type B 

20 } 

- Types 0..6 are overloaded onto a CDRtypeA, type 7 uses 

- a CDRtypeB 

CDR_network ::= ENUMERATED { 
25 unknown (0), 

TCP/IP (1), 
ISDN (2)} 

CDR_serviceTypeType ::= ENUMERATED { 
30 unknown (0), 

} 



35 



CDRJimeType ::= 

hundrethOfSec OCTET STRING (SIZE(1 )), 
seconds OCTET STRING (SIZE(1 )), 
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minutes OCTET STRING (SIZE(1)), 
hours OCTET STRING (SIZE(1 )), 
days OCTET STRING (SIZE(1 )), 

yearjo OCTET STRING (SIZE(1 )), 
year_hi OCTET STRING (SIZE(1 ))} 



CDRjdentifierType ::= SEQUENCE { 
type ENUMERATED {system_assigned(0), E164_addr(1), ...} 
data OCTET STRING (SIZE (16)) 

10 } 



CDR_paymentMethodType ::= ENUMERATED { 
free (0), - no charge 

one_time (1), - agreement valid for one payment 
periodic (2), - time-based 
wd_req (3), - payment triggered by a WD msg 
extjrig (4) - paym. trigg. by an extern, client, appl. 

} 

CDR_currencyType ::= ENUMERATED { 

majorType ENUMERATED {bill(0), E_cash(1)}, 
currency ENUMERATED {FiM (0), USD(1), ...} 

} 

- encoded in one octet so that majorType occupies 
the most significant bit and currency bits 0-6 



CDR_moneyAmountType ::= SEQUENCE { 
currency CDR_currencyType, 
value INTEGER(0..MAX_WORD) 
30 - in case E_cash is used, the value defines the 
- sequence number of the E_cash carrier CDR 



CDR_signatureType ::= SEQUENCE { 
present ENUMERATED {absent(O), present(1)}, 
35 type ENUMERATED {RSA-with-MD5(0), DES-with-MD5(1)}, 

signature OCTET STRING SIZE (64) 
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CDRformatA ::= SEQUENCE { 
type CDR_cdrType, 
5 length INTEGER (O..MAX_S_WORD), 

contractNr INTEGER (O..MAX_D_WORD), 
sequenceNr INTEGER (O..MAX_WORD), 
serviceld INTEGER (O..MAX_D_WORD), 
serviceType CDR_serviceTypeType, 

10 startTime CDRJimeType, 

endTime CDRJimeType, 
clientld CDRjdentifierType, 
watchdogld CDRjdentifierType, 
serverld CDRjdentifierType, 

15 payMethod CDRjpaymentMethodType, 

moneyAm CDRjnoneyAmountType, 
trafficData OCTET STRING (SIZE(8)) 
signature CDR_signatureType 

} 

20 

CDRformatB ::= SEQUENCE { 
type CDR_cdrType, 
length INTEGER (O..MAX_S_WORD), 
contractNr INTEGER (0..MAXJWORD), 
25 sequenceNr INTEGER (O..MAX_WORD), 

e_cash OCTET j3TRING(SIZE(0..200)) 

} 
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